Long-term Refactoring
1回のイテレーションで終わらない規模のリファクタリング。大規模モジュールの置換、永続化基盤の変更、依存関係の全面的な張り替え、アーキテクチャ移行など、数週間から数年にわたって続く改変を指す。継続的デリバリーやトランクベース開発と両立させる必要があり、長命ブランチで作業を隠すという選択肢は最初から外される。
用語自体は Martin Fowler Workflows of Refactoring (2014) の "Long Term" 節が知られているが、同じ問題は多くの呼び名で扱われてきた。本ページはその呼称マッピングと、各文献が共通して指し示している原則を整理する。
世界で何と呼ばれているか
古典的呼称 (Fowler / CD系譜)
Long-term Refactoring — Martin Fowler Workflows of Refactoring (2014)
方向を決めてから、数週間〜数ヶ月にわたり小さな前進を積み上げる。機能提供を止めない。
Branch By Abstraction — Paul Hammant Branch by Abstraction (2007) が造語
VCSの長命ブランチの代わりに、コード内に抽象を挿入して新旧実装を共存させる。
Martin Fowler BranchByAbstraction (2014) で再整理。
Jez Humble Make Large Scale Changes Incrementally with Branch By Abstraction (2011) が Continuous Delivery パターンとして位置づけ、ThoughtWorks Go の iBatis→Hibernate、Velocity→JRuby 移行を実例で示す。
Strangler Fig Application — Martin Fowler StranglerFigApplication (2004, 2024改題)
旧システムを取り囲むように新システムを育て、段階的に置換する。BBAがコード内、Stranglerがシステム外縁という対比。
Sam Newman『Monolith to Microservices』(O'Reilly, 2019) 第3章が実務向けの標準的解説。Stranglerが不可能な場合のフォールバックとしてBBAを位置づける。
Parallel Change / Expand-Contract — Danilo Sato ParallelChange (2014)
expand → migrate → contract の三段階で後方非互換な変更を安全に行う。Long-term Refactoringの最小単位の作法。
計画・可視化系
Mikado Method — Ola Ellnestam & Daniel Brolund『The Mikado Method』(Manning, 2014)
ゴールを書き、実行を試み、失敗したら前提条件をグラフに記録して戻す。葉から順に倒す。数週間〜数ヶ月の改変を可視化する技法。
英語圏での初出は InfoQ How To Do Large Scale Refactoring (2010)。
公式サイト mikadomethod.info。
Software Design X-Rays — Adam Tornhill『Software Design X-Rays』(Pragmatic Bookshelf, 2018)
バージョン管理履歴からホットスポット・変更結合を抽出し、大規模コードベースの「どこに投資すべきか」を決める。
Working Effectively with Legacy Code — Michael Feathers (2004)
seam、characterization test、Legacy Code Change Algorithm。Long-term Refactoringが前提とする作業基盤を定義した古典。
Refactoring at Scale — Maude Lemaire (O'Reilly, 2021)
Slack での数ヶ月スケールのリファクタリングのプレイブック (スコープ決定、ステークホルダ調整、進捗計測)。Nicolas Carlo の 要点まとめ がある。
Nicolas Carlo / Understand Legacy Code — 実践ブログ
Use the Mikado Method、Daily Refactoring Hour、Ship of Theseus などLong-term視点の記事群。
自動化・巨大コードベース系
変更規模が手作業の臨界点を超えると、AST変換による一括改変 (codemod) が不可欠になる。
Large-Scale Automated Refactoring Using ClangMR — Hyrum Wright ら, ICSM 2013 (PDF)
Clang AST + MapReduce で C++ モノレポ全体にAPI変更を適用。1回の実行で35,000以上の呼び出し箇所を改変した事例。
Software Engineering at Google 第22章 Large-Scale Changes — Hyrum Wright (Abseil HTML版)
Google の LSC ワークフローと Rosie パイプライン (巨大変更をシャーディングしてレビュー・提出する基盤) の公式解説。産業界の Long-term Refactoring 論で最も参照される。
Hyrum Wright Large-Scale Changes at Google: Lessons Learned From 5 Yrs of Mass Migrations — CppCon 2018
Rosie の運用知見を口頭で補完する一次資料。
Uber Piranha — Ramanathan ら (Uber Engineering, repo, ICSE SEIP 2020 論文)
陳腐化したフィーチャーフラグを自動削除するAST変換ツール。フラグ負債の削減を継続的Long-term Refactoringとして運用する事例。
jscodeshift — Felix Kling ら (Meta, GitHub)
Meta の AST変換ランナー。JS/TSの破壊的API変更を大規模コードベースに展開する際のデファクト基盤。
Mohit Thatte Refactoring with Codemods to Automate API Changes — martinfowler.com, 2025
jscodeshift系codemodをLong-term Refactoring手段として位置づける実務解説。
事例 (多年スケールのマイグレーション)
Stripe Sorbet — Paul Tarjan ら (Stripe Engineering, State of Sorbet Spring 2019)
数百万行のRubyモノリスを段階的に漸進型付けへ移行した多年計画。
Airbnb Sunsetting React Native — Gabriel Peal, 2018
2年にわたるReact Native採用とネイティブへの回帰。撤退もLong-termの一形態という事例。
Shopify Upgrading to Rails 5.0 — Rafael Franca, 2018
1年かけたデュアルブート戦略 (新旧Railsで同時稼働) + Rubocop自動修正。フレームワーク版上げのLong-termプレイブック。
学術
Tom Mens & Tom Tourwé A Survey of Software Refactoring — IEEE TSE 30(2), 2004
リファクタリング研究の標準的な背景文献。
Golubev ら One Thousand and One Stories: A Large-Scale Survey of Software Refactoring — ESEC/FSE 2021 Industry Track
1,183人の実務家調査。動機、ツールの不足、長期キャンペーン運用の実態。
Shirafuji ら Refactoring Programs Using Large Language Models with Few-Shot Examples — APSEC 2023
LLM支援リファクタリングの代表例。Long-term Refactoringの自動化がcodemodからLLMへと拡張しつつある兆候。
共通する原則
これらの文献に繰り返し現れるのは以下の原則である。個々の呼称は領域 (コード内 / システム外縁 / フラグ / 型) と粒度 (関数単位 / モジュール単位 / リポジトリ全体) の違いに過ぎない。
抽象化の挿入が前提: 差し替え可能な境界を先に作る。BBAはこれを明示化した名前である。インタフェース化されていないものをインタフェースに変える工程はLong-term Refactoringの開始地点であり、それ自体はリファクタリング (振る舞いを変えない変形) ではない。
本番との並走: 旧実装と新実装を同時に動かし、段階的に切り替える。Strangler Fig と Parallel Change が別粒度で同じことを言っている。
小さな前進の連鎖とグラフによる可視化: Mikado は依存を木で可視化し葉から倒す。Software Design X-Rays は履歴からホットスポットを特定する。数ヶ月スケールの作業は、全体を一度に把握せず局所的な次の一手の連鎖として進める。
データとコードの非対称性: スキーマ変更は Expand-Contract が必須。コードと違って「元に戻す」コストが桁違いに大きいため、拡張→移行→収縮の三段階を省略できない。
退却可能性の維持: 各時点で切り戻し可能な状態を保つ。Humble の CD 論、Google LSC、Shopifyのデュアルブートはいずれもこの条件を満たすよう設計されている。
自動化の臨界点: 数千〜数万箇所の改変が必要になるとcodemod/AST変換が不可欠になる。ClangMR、Rosie、jscodeshift、Piranha はこの臨界点を超えた領域の道具。LLM支援はこの境界をさらに曖昧にしつつある。
継続的な習慣化: Daily Refactoring Hour のように、英雄的なスプリントではなく日次のリズムとして埋め込む方が持続する、という実務知見が繰り返し現れる。
呼称は違っても、変化のコストを時間軸に分散させ、本番を止めず、いつでも退却できる状態で前進する、という構造は共通している。